Как знают администраторы систем хранения данных, у различных компонентов SAN-сети есть такой параметр как глубина очереди (Queue Depth). Он есть у HBA-адаптера сервера (на котором, например, работает VMware ESX / ESXi) и у порта Storage Processor'а системы хранения (SP). Глубина очереди определяет сколько операций ввода-вывода (IO) может быть одновременно обработано на устройстве.
Как мы уже писали, если до SP со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (T) должна удовлетворять следующему соотношению:
T >= Q*L,
где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.
Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:
T>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.
Queue Depth на серверах
По умолчанию, для хостов VMware ESX / ESXi значение Queue Depth равно 32, как его изменить, читайте у нас тут и вот тут. Теперь внимание: этот параметр имеет значение только когда у вас только одна виртуальная машина на хост-сервере использует конкретный LUN. Если его используют уже 2 машины, то он игнорируется, а в действие вступает следующая расширенная настройка (Advanced Setting - как его задавать описано тут):
Disk.SchedNumReqOutstanding (DSNRO)
Этот параметр также по умолчанию равен 32. Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN. То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в статье Jason Boche, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32:
Здесь видно, что активно выполняется 30 команд (максимально 32) для параметра DQLEN, а остальные 67 остаются в очереди. То есть параметр определяет максимальную планку в IO как для одной машины на LUN, так и для всех машин на LUN.
Важно, чтобы параметры Queue Depth и DSNRO были установлены в одно и то же значение. Это рекомендация VMware. Так что, если вздумаете изменить один из них - не забудьте и про второй. И помните, что параметр DSNRO для хоста - глобальный, а значит будет применяться ко всем LUN, подключенным к хосту.
Target Port Queue Depth на массивах
Для дискового массива (а точнее, SP) очередь - это то, куда он сладывает SCSI-команды в то время, пока обрабатывается и выполняется пачка предыдущих. Нормальный midrange-массив имеет глубину очереди 2048 и более. Если массив получает в очередь команд IO больше значения Target Port Queue Depth, то он назад выдает команду QFULL, которая означает, что очередь заполнена и хост-серверу нужно с этим что-то делать. VMware ESX / ESXi реагирует на это следующим образом - он уменьшает очередь на LUN и периодически (каждые 2 секунды) проверяет, не исчезло ли QFULL, и если исчезло, то начинает постепенно увеличивать глубину очереди для этого LUN (это может занять до одной минуты). Это и есть причины тормозов, которые часто возникают у пользователей VMware ESX / ESXi.
Как управлять очередью и адаптивный алгоритм VMware
Теперь становится понятным, почему мы сразу не выставляем параметр Disk.SchedNumReqOutstanding на хостах VMware ESX / ESXi в максимальное значение - мы можем вызвать QFULL на SP массива. С другой стороны, уменьшать его тоже нехорошо - мы ограничим количество операций IO с хоста на LUN.
Поэтому здесь нужен гибкий подход и он есть у VMware (adaptive queue depth algorithm). Работает он таким образом: мы его активируем с помощью параметров Disk.QFullSampleSize и Disk.QFullThreshold в Advanced Settings. Они влияют вот на что:
QFullSampleSize - если число число ответов QFULL (оно же BUSY) превысит его, то ESX / ESXi наполовину обрежет глубину очереди (LUN queue depth)
QFullThreshold - если число ответов о том, что QFULL или BUSY больше нет, превысит его, то ESX / ESXi будет постепенно увеличивать LUN queue depth на 1 (вроде бы, каждые 2 секунды).
Но сколько бы не уменьшалось DQLEN - ниже заданного нами значения DSNRO оно не упадет. Это защищает нас от неожиданного провала в производительности. Кстати, эти параметры тоже глобальные - так что если один (например, тормозящий) массив с хоста будет подвергаться такому адаптивному эффекту со стороны ESX / ESXi, то и для другого (например, производительного) тоже будут выполняться такие фокусы.
Теперь, что дополнительно можно почитать на эту тему:
То есть мораль всей басни такова - дефолтные зачения DSNRO и Queue Depth подходят для большинства случаев. Но иногда имеет смысл изменить их. Но в этом случае надо учитывать параметры системы хранения данных, структуру SAN, количество LUN и другие параметры, влияющие на производительность ввода-вывода.
Как вы знаете, есть такой хороший продукт vGate 2, который производится нашим спонсором - компанией "Код Безопасности" (об основных его возможностях можно почитать в нашей статье). Нужен он для двух важных с точки зрения информационной безопасности вещей: защиты компонентов VMware vSphere от несанкционированного доступа (НСД) и автоматической настройки среды VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги, которые вы должны были бы потратить на консультантов, обучение своих специалистов и ручную настройку виртуальной среды).
Кстати, важная новость. Вышел vGate 2 с полной поддержкой VMware ESXi 4.1 (об этом мы писали тут, но продукт был еще в бете). Скачать vGate 2 для VMware ESXi можно тут.
Но сегодня мы поговорим о том, как было бы неплохо организовать безопасную инфраструктуру доступа системных администраторов VMware vSphere к различным компонентам среды виртуализации. Это нужно для того, чтобы понимать как правильно наладить контроль за серверами ESX / ESXi и виртуальными машинами со стороны vGate, а также разграничить доступ к этим объектам в рамках зон ответственности администраторов vSphere.
Логичной выглядит следующая схема построения локальной сети в контексте доступа к компонентам виртуальной инфраструктуры:
Немного опишем ее:
Выделяем на уровне домена безопасности отдельно сеть администрирования инфраструктуры vSphere. Она содержит серверы ESX / ESXi, сервер vCenter, а также сервер авторизации vGate. Сам сервер авторизации имеет два сетевых адаптера - одним он смотрит в сети администрирования vSphere, а другим во внешнюю сеть предприятия, где находятся рабочие станции администраторов. Таким образом из последней сети в сеть управления можно попасть исключительно через сервер авторизации vGate (компоненты vGate выделены зеленым). На рабочих местах администраторов vSphere и администратора ИБ также установлены клиентские компоненты vGate.
В отдельную подсеть нужно выделить сеть репликации ВМ (та, что для vMotion и Fault Tolerance).
В отдельную подсеть выделяем сеть для IP-хранилищ (NFS/iSCSI).
Ну и, само собой, сеть виртуальных машин тоже должна быть отдельной. Разделение сетей на хостах ESX / ESXi лучше делать на базе тегирования на уровне виртуального коммутатора (см. виды тэгирования).
Если взглянуть на разделение сетей со стороны сетевых адаптеров хост-сервера ESX сервера авторизации vGate, мы получим такую картину:
После конфигурирования локальной сети обязательно следует настроить маршрутизацию между подсетями, а также убедиться в наличии доступа с рабочих мест администраторов vSphere к элементам управления виртуальной инфраструктурой (vCenter и хост-серверы).
Вот основные варианты настройки маршрутизации (АВИ - это администратор виртуальной инфраструктуры):
При внесении различных параметров в конфигурационные файлы виртуальной машины на VMware ESX могут возникнуть различные ошибки. При этом виртуальная машина может до некоторого времени работать корректно.
Есть способ проверить vmx-файл на предмет наличия в нем ошибок (опечаток, например, в путях к рабочим директориям и т.п.). Для этого есть команда:
/usr/bin/vmware-configcheck <путь к vmx-файлу>
Она проверяет его на соответствие правилам оформления, приведенным в файле /etc/vmware/configrules.
В случае успешной проверки результат будет таким:
А в случае неуспешной - будет выведен результат FAIL и описание ошибки конфигурации.
В первой части статьи о файлах журнала VMware ESX (логах) мы описали их размещение и назначение. Но поскольку готовящаяся к выходу платформа VMware vSphere 5 будет построена только на базе платформы VMware ESXi (см. нашу серию статей), то сегодня мы поговорим о том, где находятся логи ESXi и как их можно посмотреть.
Если открыть консоль ESXi через консоль Tech Support Mode или по SSH мы можем увидеть следующую структуру основных логов:
/var/log/vmware/hostd.log – это лог службы хоста VMware ESXi (host daemon - служба, управляющая хостом)
/var/log/vmware/vpx/vpxa.log – лог агента vCenter (который управляет через агент хоста). Этого лога не будет если ESXi работает не под управлением vCenter.
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
/var/log/sysboot.log - System boot log (лог загрузчика хоста)
/var/log/vmware/aam/vmware_<hostname>-xxx.log - Automatic Availability Manager (AAM) logs (лог агента VMware HA). Этого лога не будет если ESXi работает не под управлением vCenter.
NB: Обратите внимание, что при установке VMware ESXi по умолчанию логи хранятся в разделе Scratch Partition, который находится в памяти в виде RAM-диска. После перезагрузки хоста - они будут удалены, если вы не настроили этот раздел для хранения, в том числе, логов.
Теперь как эти логи на ESXi можно посмотреть. Есть аж 5 способов.
1. Через DCUI (Direct Console User Interface).
В главном меню System Customization, куда вы попадаете по кнопке F2 на самом сервере, выберите пункт "View System Logs":
Также в DCUI можно по комбинации клавиш Alt+F12 увидеть лог vmkernel.
Также вы можете зайти в консоль и перейти в папку с логами (/var/logs):
2. Через веб-браузер.
Просто наберите в адресной строке https://<esxi ip address>/host, после чего введите имя пользователя и пароль root.
3. Использование Syslog-сервера для VMware ESXi.
Вы можете настроить Syslog-сервер для ваших хостов ESXi в целях организации удаленного логирования. Для этих целей вполне можно использовать бесплатный продукт vSphere Management Assistant (vMA). Подробно это описано тут:
Кстати, по умолчанию сообщения логов vpxa и hostd (/var/log/vmware/vpx/vpxa.log и /var/log/vmware/hostd.log) дублируются в /var/log/messages. Если вы хотите это отключить (чтобы там было меньше флуда), используйте вот эту заметку.
Продолжаем вас знакомить с решением vGate 2 от компании Security Code, которая является нашим спонсором (вот тут описано решение, а вот тут - специальный раздел о продукте). Вкратце: vGate 2 позволяет защиту объектов VMware vSphere от несанкционированного доступа, а самое главное - позволяет автоматически настроить среду VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги). Кстати, недавно вышла версия vGate 2.3 с поддержкой VMware ESXi.
Сегодня мы поговорим о мониторинге и аудите событий информационной безопасности, происходящих в виртуальной инфраструктуре VMware vSphere. Надо сказать, что для тех компаний, которые заботятся о безопасности своих виртуальных серверов, анализировать стандартные логи, которые дает ESX и vCenter весьма муторно:
На хостах ESX структура логов (откуда мы и можем выделить события ИБ) такова:
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
Вручную разгребать и анализировать всю эту пачку весьма трудозатратно, поэтому vGate 2 дает вам возможность сделать это удобно из центральной консоли в едином Журнале событий. Но vGate 2 - это не обработчик логов на хостах VMware ESX / ESXi. За счет собственных агентов на хост-серверах он сам регистрирует все события, относящие к информационной безопасности инфраструктуры виртуализации. Это именно те события, аудит которых позволяет своевременно обнаружить и пресечь попытки несанкционированного доступа.
События безопасности регистрируются на всех серверах ESX, на которых установлены компоненты защиты vGate (агенты), а затем пересылаются на сервер авторизации для централизованного хранения. Регистрируются как события несанкционированного доступа к объектам vSphere, так и правомочные события.
Если открыть одно события из списка, мы увидим нечто подобное (доступно полное детальное описание - кто сделал, что, когда и с какого хоста):
События имеют следующие характеристики:
vGate 2 отслеживает те события, которые могут тем или иным образом повлиять на безопасность виртуальной инфраструктуры. Как примеры таких событий можно привести следующее:
Также, помимо основных событий, vGate 2 регистрирует еще и события, связанные с нарушением контроля целостности (КЦ) в различных компонентах виртуальной инфраструктуры:
На серверах ESX (папка /opt/vgate)
На сервере авторизации (каталог установки vGate)
На рабочей станции администратора VMware vSphere
На рабочей станции администратора безопасности инфраструктуры vSphere
Кстати, на компьютерах внешнего периметра сети администрирования (то есть рабочих станциях с vSphere Client), на которых установлен агент аутентификации, сообщения хранятся локально в журнале при
ложений Windows (Application Event Log). Для их просмотра (локально или удаленно) можно использовать Windows Event Viewer.
В этом документе вы найдете полное описание событий ИБ на хостах VMware ESX / ESXi, которые регистрирует vGate 2.
В заключение скажем, что vGate 2 имеет возможность интеграции с SIEM-системами, если таковые имеются на вашем предприятии. vGate позволяет настроить ведение журнала событий и поддерживает протокол SNMP, что позволит при необходимости перенаправить события из журнала событий vGate на удаленный сервер.
Как оказалось, на нашем сайте нет хорошего руководства по назначению и использованию RDM-дисков (Raw Device Mapping) с платформой VMware vSphere. Постараемся заполнить этот пробел.
Давайте начнем с того, что для виртуальных машин на серверах VMware ESX есть всего 3 типа дисков с точки зрения виртуализации подсистемы хранения:
VMDK-диски
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion - и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски - это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором - это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS - не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом - основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе - дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности - например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
Как вы знаете, мы сотрудничаем с компанией "Код Безопасности", которая, в частности, занимается выпуском продукта vGate 2, который автоматизирует настройку виртуальной среды в соответствии с регламентами предприятия, а также руководящими документами и стандартами в этой сфере (см. тут). Кроме того, он позволяет организовать инфраструктуру полномочного доступа к компонента виртуальной инфраструктуры VMware vSphere и защитить ее от несанкционированного доступа (см. тут).
Недавно стала доступна для скачивания бета-версия продукта vGate 2.3, который полностью поддерживает платформу VMware ESXi 4.1. А это очень важно, поскольку vSphere 5 будет построена только на базе ESXi, а ESX уйдет в прошлое (см. нашу серию статей тут). Само собой, к выходу vSphere 5 продукт vGate будет готов обеспечивать безопасность этой платформы.
Итак, прежде всего, ссылка на скачивание vGate 2.3 с поддержкой ESXi: http://www.securitycode.ru/products/demo/. В поле "Выберите продукт" выбираем "Бета-версия vGate 2 (с поддержкой ESXi)".
Для поддержки ESXi была проделана большая работа - представьте сколько всего нужно было переделать, чтобы доработать агента для хост-серверов и договориться с VMware о его сертификации для ESXi. Под "все" подразумевается настройка конфигурации хост-серверов ESXi для соответствия политикам безопасности VMware Security Hardening и другим.
Важно! Для серверов виртуализации VMware ESXi пока поддерживаются только следующие политики:
Запрет клонирования виртуальных машин;
Запрет создания снимков виртуальных машин;
Список запрещенных устройств;
Доверенная загрузка виртуальных машин;
Запрет подключения USB-носителей к ESX-серверу;
Очистка памяти виртуальных машин;
Запрет доступа к консоли виртуальной машины;
Запрет доступа к файлам виртуальных машин;
Затирание остаточных данных на СХД при удалении ВМ;
Запрет смешивания разных типов сетевого трафика.
Кстати, если у вас есть инфраструктура VMware View 4.5 - то vGate 2.3 ее поддерживает (в документации описано, что нужно сделать).
В продукте появилось еще несколько интересных возможностей:
Поддержка стандартного Distributed vSwitch (dvSwitch)
Новые политики безопасности:
Запрет Download файлов ВМ с привязкой к меткам
Запрет трафика vMotion (FT) и трафика vSphere Client
Затирание остаточных данных на СХД при удалении ВМ
Запрет доступа к консоли ВМ с привязкой к меткам
Соответствие стандарту PCI-DSS
Обновлен установщик продукта, улучшено управление генерацией событий
Сервер авторизации полностью поддерживается в ВМ
Шаблоны настроек политик АС по ФСТЭК, ИСПДн по ФСТЭК, ИСПДн по СТО БР ИББС
В продолжение темы "Как сбросить пароль root на VMware ESX". У Dave Mishchenko есть отличная инструкция о том, как сбросить пароль пользователя root на хосте VMware ESXi в том случае, если вы его потеряли, забыли или съели. Работает эта инструкция и для VMware ESXi 4.1 (а также 4.0 и даже 3.5). Переведем ее вкратце.
1. Допустим хост VMware ESXi у вас сейчас работает и вы можете выполнять на нем команды локально или по SSH. Тогда имеет смысл выполнить команду:
cat /etc/shadow
Видим картинку с хэшем пароля рута:
Хэш пароля - это то, что написано после root : до следующего двоеточия (само двоеточие не включается). Хэш этот нужно записать на случай, если его понадобится восстановить назад.
2. Дальше нужен какой-нибудь Linux live CD. Предлагается использовать Slax Linux Live CD.
Далее просматриваем смонтированные разделы сервера ESXi командами:
fdisk -l (смотрим подходящие FAT16 разделы, где у нас размещен загрузчик)
ls -l /mnt/sda5/ (основной, при загрузке монтируется как /bootbank)
ls -l /mnt/sda6/ (резервный, при загрузке монтируется как /altbootbank)
В случае чистой установки ESXi, картина будет такова:
Нас интересует файл state.tgz - там все, что нам нужно. Если у вас ESXi Embedded то нужен файл local.tgz (который в первом случае находится внутри state.tgz).
Распаковываем сначала state.tgz, а потом local.tgz командами gzip и tar во временную директорию. Далее заходим в ней в папку /etc и открываем в ней файл shadow командой:
vi shadow
У вас откроется что-то вроде того:
Теперь посмотрите на картинку ниже, мы удаляем хэш пароля из этого файла:
То есть убираем все то, что между двумя двоеточиями. Выходим из файла, сохранившись.
Теперь все это упаковываем назад, для чего во временной папке (туда надо подняться из /etc) выполняем такую команду (апдейтим архив изменившейся папкой):
tar -czvf local.tgz etc
Если вы используете ESXi Embedded - кладете файл local.tgz на место, откуда брали. Если обычный ESXi - снова апдейтим архив:
tar -czvf state.tgz local.tgz
И также копируем туда, где он лежит:
Перезагружаем сервер и уже загружаемся в VMware ESXi. Видим такую картинку:
Это значит - все получилось. Теперь можем заходить в консоль под пользователем root с пустым паролем. Вот такой незамысловатый способ сброса пароля на хосте VMware ESXi.
Вы уже все знаете про продукт StarWind Enterprise iSCSI (но еще не все купили), который позволяет создавать отказоустойчивые хранилища для виртуальных машин VMware vSphere и Microsoft Hyper-V (у нас есть, кстати, специальный раздел о StarWind). Недавно мы писали о том, что вышла бесплатная версия StarWind Free.
А сегодня еще одна приятная новость для задумавшихся о покупке продукта - теперь StarWind Enterprise полностью сертифицирован со стороны VMware в качестве системы хранения по программе VMware Certified Partner. Вы можете обнаружить его в HCL-листе:
Из пресс-релиза:
StarWind iSCSI SAN software has successfully passed all the laboratory tests and has met all the interoperability criteria required by VMware.
This certification assures our customers that StarWind solution is officially compatible with VMware virtualization products and guarantees full VMware technical support for any VMware infrastructure built using StarWind iSCSI SAN.
Так что теперь можете смело показывать руководству, что iSCSI-хранилища StarWind Enterprise - это сертифицированное VMware решение.
Начните хотя бы с бесплатной версии - это не потребует от вас ничего кроме обычного Windows-сервера, который даже может быть виртуальным. Кстати, скоро выйдет версия StarWind Enterprise 5.7, где будет еще больше возможностей.
Те, кто увлекается разработкой сценариев на PowerShell на фреймоврке PowerCLI, наверное помнят про бесплатную раздачу постеров на блоге VMware. Тогда не все успели забрать свой постер.
Сейчас они пишут, что раздача закончена. Но не беда - вы без проблем можете забрать свой постер по PowerCLI по этой ссылке. А вот еще версия для распечатки на листах А4.
Вы все уже давно поняли, что нужно думать о безопасности виртуальной инфраструктуры VMware vSphere. Лучше всего думать о ней таким способом: попробовать продукт vGate, который автоматизирует настройку виртуальной среды в соответствии с регламентами предприятия, а также руководящими документами и стандартами в этой сфере. Сегодня мы рассмотрим безопасность инфраструктуры виртуализации с экономической точки зрения: попробуем ROI-калькулятор для решения vGate.
Я уже, наверное, набил вам оскомину, но снова повторюсь - в версии VMware vSphere 5, которая выйдет в августе-сентябре (в подтверждение этому - посмотрите на книжку на Amazon, которая выходит 7 сентября), уже не будет платформы виртуализации VMware ESX. Останется только "тонкая" платформа VMware ESXi. Поэтому всем организациям необходимо планировать миграцию с ESX на ESXi. Об этом у нас есть серия постов:
В нем нам рассказывают о том, как нужно управлять виртуальной инфраструктурой VMware vSphere на базе VMware ESXi, и какие методики используются в сравнении с моделью управления на классическом ESX:
Для готовящихся к миграции и имеющих различные скрипты и агентов в сервисной консоли серверов ESX - читать обязательно.
На сайте проекта VMware Labs (о котором мы уже писали), появилась утилита для сохранения иерархии объектов и их конфигурации на VMware vCenter под названием VMware InventorySnapshot.
С помощью InventorySnapshot можно сохранить иерархию и параметры: папок датацентра (Datacenter folders), сами датацентры (datacenters), кластеры VMware HA/DRS и их настройки, пулы ресурсов (resource pools), виртуальные приложения (vApp), иерархию объектов, роли и пермиссии, а также настраиваемые поля объектов (custom fields).
Далее на основании снапшота генерируется PowerCLI скрипт, который потом можно выполнить на любом другом окружении vCenter. Это полезно, например, когда у вас есть тестовое окружение, конфигурацию которого вы хотите перенести в производственную среду на другом vCenter (вручную делать это может оказаться слишком нудным).
Как вы уже знаете, VMware vSphere 5 будет уже только на базе гипервизора ESXi, а выпуск продукта ESX прекращается (версия 4.1 - последняя на базе этой платформы). Поэтому тем, кто еще не перешел на VMware ESXi нужно задумываться о миграции.
Мы уже писали на тему того, как перейти с ESX на ESXi (тут, тут и тут), а сегодня расскажем в общих чертах о плане миграции таких хост-серверов и о том, что делать после установки нового ESXi (пост-миграционные процедуры).
Как вы знаете, есть такой продукт vGate 2 от российского разработчика "Код Безопасности", который нужен для защиты информации от несанкционированного доступа и контроля выполнения политик безопасности для виртуальной инфраструктуры на базе платформ VMware Infrastructure 3 и VMware vSphere 4. Также он облегчает приведение виртуальной инфраструктуры в соответствие законодательству и отраслевым стандартам информационной безопасности (и также имеет сертификат ФСТЭК).
Мы уже описывали основные возможности и архитектуру vGate 2 для VMware vSphere, а сегодня поговорим более детально о важной функциональной составляющей продукта - настройке политик безопасности и имеющихся встроенных политиках.
Политики безопасности, реализованные в vGate, контролируют критичные для безопасности виртуальной среды настройки серверов ESX и ВМ. Помните те самые политики, на предмет соответствия которым вы сканировали инфраструктуру виртуализации с помощью бесплатного средства vGate Compliance Checker? Так вот теперь их можно задать для хостов VMware ESX, а также виртуальных машин. И, соответственно, привести их в соответствие с этими политиками.
Основная идея таких политик - облегчить жизнь администратору виртуальной инфраструктуры VMware vSphere при работе с серверами VMware ESX / ESXi в ситуации, когда есть необходимость защиты данных виртуальных машин. Поскольку виртуализация, зачастую, полностью меняет подход к управлению виртуальной инфраструктурой, список требований к безопасности существенно увеличивается (см., например, как украсть виртуальную машину или наши записи с тэгом Security).
Так вот, когда у вас в компании есть администратор информационной безопасности, продукт vGate 2 - это лучший способ настроить виртуальную инфраструктуру с помощью политик так, чтобы он не мог прикопаться к администратору vSphere, поскольку все будет сконфигурировано в соответствии с отраслевыми стандартами, а значит потенциальные дырки будут закрыты.
То есть, сакральный смысл политик в vGate 2 - освободить администратора vSphere от геморроя по удовлетворению требований безопасников за счет автоматизации настройки безопасности для хостов и виртуальных машин. Все просто и нужно.
Политики безопасности vGate 2 объединены в наборы (они же шаблоны). Эти шаблонов целых пять штук:
Набор политик
Описание
vGate
Специально разработанный аналитиками компании Код Безопасности для vGate базовый набор политик, включающий в себя политики для ESX-серверов и ВМ
CIS 1.0
Набор политик для быстрого приведения виртуальной среды в соответствие рекомендации CIS VMware ESX Server 3.x Benchmark (v 1.0)
PCI DSS
Набор политик для быстрого приведения виртуальной среды в соответствие требованиям PCI DSS 1.2. Это типа для всяких контор, которые работают с платежными системами.
Набор политик для быстрого приведения виртуальной среды в соответствие рекомендации CIS VMware ESX Server 3.5 Benchmark
(v 1.2.0)
Позырим на самый простенький шаблон политик с одноименным названием vGate, который обеспечивает базовую настройку безопасности на хостах ESX и ВМ.
Для ESX:
Список разрешенных программ - на ESX-сервере хранится список разрешенных по умолчанию программ. Безопасник или админ может добавить или
удалить из этого списка нужные программы.
Запрет локального входа
на ESX-сервер - указываем пользователей для входа в консоль.
Запрет подключения USB-носителей - после применения надо перезагрузиться.
Правила для межсетевого экрана - содержит правила фильтрации трафика для межсетевого экрана netfilter, поступающего на ESX-сервер(по умолчанию политика запрещает административный доступ по портам TCP 443/22 для всех объектов из за-
щищаемого периметра за исключением сервера авторизации и vCenter - админы ходят клиентом через сервер авторизации).
Для виртуальных машин:
Список запрещенных устройств - всякую фигню не подключишь.
Запрет клонирования виртуальных машин - не склонируешь и не украдешь.
Запрет создания снимков виртуальных машин - снапшоты это вообще плохо (не только в плане безопасности).
Проверка целостности виртуальных машин - контроль целостности и доверенной загрузки ВМ перед стартом.
Очистка памяти виртуальной машины - после завершения ее работы (нужна перезагрузка ВМ).
Ну а дальше идут шаблоны, отвечающие различным общепринятым стандартам (там очень много пунктов, полный список здесь). Самый разумный из них - VMware Security Hardening Best Practice, там есть реально нужные в жизни вещи.
Кстати, делается это все за счет агентов, работающих на серверах ESX и устанавливаемых туда с сервера авторизации (см. статью).
Назначение политики делается так:
Делаем из шаблонов набор политик (можно комбинировать шаблоны и отдельные политики):
Назначаем для категории или уровня конфиденциальности (метки безопасности) этот набор:
Далее объекту (ESX-серверу или ВМ) назначаем эту метку безопасности.
Потом проходит некоторое время (его можно настраивать, по дефолту - 10 минут) и политики применяются. Работает - само.
Теперь, что еще нужно сказать о vGate 2. Во-первых, просили зафигачить ссылку на вот это видео (http://www.sltv.ru/comments/clip-1812/) - там вам пафосным голосом расскажут о продукте. Во-вторых, вы можете написать все, что думаете о vGate 2 вот в этой форме, а также в комментариях здесь. Сотрудники Кода Безопасности ответят на ваши вопросы.
Теперь у вас есть полностью бесплатный StarWind iSCSI Target, чтобы создавать хранилища для виртуальных машин на базе существующей Ethernet-инфраструктуры и без каких-либо вложений. Дальше уже можно задуматься о коммерческом издании StarWind CDP или средстве создания отказоустойчивых хранилищ StarWind Enterprise HA.
Новая бесплатная версия StarWind Free Edition позволит вам использовать многие серьезные возможности, которые есть только у коммерческих продуктов:
Любую современную хостовую операционную систему Windows Server для сервера хранилища. Можно использовать локальные диски серверов для создания томов VMFS с поддержкой VMware HA/DRS и других распределенных служб.
Можно создавать хранилища для виртуальных машин VMware vSphere, Microsoft Hyper-V, Citrix XenServer и других систем виртуализации.
Дедупликация данных (с различными размерами блоков). Это позволяет экономить дисковое пространство на системе хранения, убирая дублированные блоки.
Полностью разрешенное лицензией использование хранилищ в производственной среде.
Поддержка! Для бесплатной версии идет basic support plan, что подразумевает поддержку через форум на сайте. Далее можно покупать поддержку по инцидентам, а также переключиться на любое коммерческое издание без дополнительных доплат (в платите только разницу между изданиями).
Caching - в StarWind iSCSI есть хороший механизм кэширования (write-back и write-through), ускоряющий работу виртуальных машин с хранилищами.
Функции VTL (Virtual Tape Library) и репликация по сети WAN доступны как возможность платного обновления на коммерческую версию.
Поддержка возможностей Thin Provisioning в StarWind - ваше хранилище для виртуальных машин (образ виртуального диска) будет расти по мере наполнения его данными.
Как вы знаете, есть такой хороший продукт StarWind Enterprise iSCSI, о котором мы уже немало писали и сделали специальный раздел. Он позволяет вам сделать отказоустойчивое iSCSI-хранилище для виртуальных машин VMware vSphere или Microsoft Hyper-V на базе любого устройства хранения, в том числе обычного Windows-сервера с локальными дисками.
Сегодня мы поговорим о том, что нам нужно сделать с сервером StarWind Enterprise, чтобы у нас была безопасная конфигурация хранилища, и никто лишний не смог бы к нему подключиться.
Во-первых, когда мы установили StarWind, то к нему можно подключиться с помощью StarWind Management Console, установленной локально на сервере или на другой рабочей станции. По умолчанию для подключения к серверу используется логин root и пароль starwind. Это нужно изменить. Меняется это вот тут:
Во-вторых, само собой, StarWind Enterprise поддерживает CHAP-аутентификацию клиентов (с паролем от iSCSI инициатора к таргету). Ее можно настроить, зайдя в свойства таргета StarWind и перейдя на вкладку "CHAP Permissions". Там нужно нажать правой кнопкой на белом поле и выбрать Add Permission:
Ну и, в-третьих, можно настроить разрешения для IP-адресов клиентов, которые могут соединяться с определенными таргетами по определенным сетевым интерфейсам. Для этого нужно зайти в свойства таргета StarWind и, перейдя на вкладку "Access Rights", нажать правой кнопкой на белом поле и выбрать Add Rule:
Все эти три вещи рекомендуется настраивать для производственного хранилища StarWind Enterprise iSCSI.
Дорогие читатели. Как вы знаете, мы сотрудничаем с компанией "Код Безопасности", которая является разработчиком сертифицированных средств для обеспечения безопасности ИТ-инфраструктуры. В частности, они делают продукт vGate 2 for VMware, который позволяет автоматизировать работу администраторов по конфигурированию и эксплуатации системы безопасности, а также облегчает приведение виртуальной инфраструктуры на платформах компании VMware в соответствие законодательству и отраслевым стандартам.
Это очень важно для многих тех из вас, которые видят перед собой призрак закона ФЗ 152 о персональных данных. Ну и для тех из вас, конечно, кто хочет эти данные в виртуальной инфраструктуре vSphere защитить. Тем более, что виртуализация открывает множество новых источников угроз.
Надежность vGate подтверждает и сертификат ФСТЭК России №2308.
Тыкаем на ссылку и регистрируемся. Не каждый день девушки вам рассказывают о безопасности виртуальной ИТ-инфраструктуры VMware vSphere.
Ну и описание вебинара по vGate 2:
На вебинаре «Автоматизация работы администраторов по конфигурированию и эксплуатации системы безопасности виртуальной инфраструктуры» будут рассмотрены возможности разделения объектов инфраструктуры на логические группы и сферы администрирования, автоматического приведения виртуальной инфраструктуры в соответствие положениям законодательства и отраслевых стандартов, а так же контроля над изменениями на основе заданных корпоративных политик.
На вебинаре будет представлено решение для защиты виртуальных инфраструктур компании «Код Безопасности» - vGate 2. В конце вебинара будет проведена демонстрация его работы.
Вебинар будет интересен всем специалистам, которые работают с виртуальными инфраструктурами или планируют перейти на их использование, а также специалистам по информационной безопасности занимающимся обеспечением их защиты.
Докладчик: Сидорова Мария, заместитель руководителя направления «Защита виртуальных инфраструктур», компания «Код Безопасности»
Это, по-сути, средство сбора отчетности о виртуальной инфраструктуре VMware vSphere и виртуальных машинах, что-то вроде бесплатного Veeam Reporter Free.
В категории Performance мы можем увидеть следующую информацию:
Host/VM Utilization Heat Map - в этой категории представлены хосты и виртуальные машины с наибольшей загрузкой вычислительных ресурсов. Весьма полезно для развертывания новых ВМ.
Host Top CPU Ready Queue - параметры метрики производительности CPU Ready. Подробнее об этом счетчике тут.
Storage Access IOPS - здесь мы видим нагрузку на виртуальные хранилища по IOPs (на и из Datastore).
В категории Efficiency мы можем увидеть следующую информацию:
VM Over/Under Provisioning - показывает недогруз или перегруз по ресурсам для виртуальных машин на хост-серверах.
Storage Wasted Allocations - ранжированно показывает, где у нас на хранилище лежит непойми что (не относящееся к ВМ) и их недозаполненность.
Storage Allocated to Dormant VMs - показывает какие ВМ не используются и сколько выделено под них хранилища.
VM Rightsizing Recommendations - показывает рекомендации по сайзингу ВМ с точки зрения производительности (типа добавить или удалить vCPU).
Но этот продукт для небольшой инфраструктуры, а нормальные пацаны с табуном серверов ESX / ESXi скачивают и покупают продукт Veeam Reporter, который позволяет вести трекинг изменений виртуальной инфраструктуры VMware vSphere и получать отчетность обо всех ее аспектах. Тем более, что недавно вышел бесплатный аддон к нему - Capacity Planning Report pack for Veeam Reporter.
Скачать же бесплатный VMTurbo Performance and Efficiency Reporter можно по этой ссылке.
Как вы знаете, VMware vSphere 5 будет построена только на базе гипервизора VMware ESXi (а ESX больше не будет) и выйдет уже в этом году, поэтому мы публикуем серию заметок о том, как перейти на ESXi с ESX (вот тут - раз и два).
Сегодня мы поговорим о таком различии, как Scratch Partition в ESXi. Scratch Partition - это специальный раздел на хранилище для хост-сервера, который не обязательно, но рекомендуется создавать. Он хранит в себе различную временную информацию для ESXi, как то: логи Syslog'а, вывод команды vm-support (для отправки данных в службу поддержки VMware) и userworld swapfile (когда он включен). Он создается, начиная с vSphere 4.1 Update 1 автоматически, и, если есть возможность, на локальном диске.
Так как данный раздел является необязательным, то в случае его отсутствия вся перечисленная информация хранится на ramdisk хост-сервера (который, кстати, отъедает память - 512 MB). И, так как это ramsidk, после перезагрузки эта информация (если у вас нет scratch partition) очищается. Поэтому неплохо бы этот раздел, все-таки, создать.
По умолчанию, этот раздел создается в системе vfat и составляет 4 ГБ. Это много. Почему так много? Объяснение такое, что местечко оставлено под будущие версии ESXi. Этот раздел может размещаться локально или на SAN-хранилище. При этом его могут использовать несколько хостов ESXi одновременно, поэтому рекомендуется сделать его гигов 20. Но для каждого должна быть своя locker-директория на этом разделе.
Через vSphere Client scratch partition настраивается так:
Соединяемся с хостом ESXi из vSphere Client.
Переходим на вкладку Configuration.
Переходим в категорию Storage.
Нажимаем правой кнопкой на datastore и выбираем Browse.
Создаем уникальную директорию для хоста ESXi (например, .locker-ESXiHostname)
Закрываем Datastore Browser.
Переходим в категорию Software.
Нажимаем Advanced Settings.
Переходим в раздел ScratchConfig.
Устанавливаем в качестве значения ScratchConfig.ConfiguredScratchLocation директорию, которую только что создали, например:
/vmfs/volumes/DatastoreName/.locker-ESXiHostname
Нажимаем OK.
Перезагружаем ESXi.
Все это можно настроить и при автоматизированном развертывании VMware ESXi через kickstart. А можно и через vCLI и PowerCLI. О том, как это сделать, читайте в KB 1033696.
Как вы знаете, в рамках партнерства с компанией Код Безопасности мы будем вас знакомить с продуктом vGate 2, который позволяет автоматизировать работу администраторов по конфигурированию и эксплуатации системы безопасности, а также облегчает приведение виртуальной инфраструктуры на платформах компании VMware в соответствие законодательству и отраслевым стандартам.
Мы уже много писали о таком документе как VMware vSphere Security Hardening (есть также и версия для VMware View), который описывает основные принципы и приемы обеспечения информационной безопасности VMware vSphere и виртуальных машин (без учета гостевых ОС).
Так вот, недавно компания VMware выпустила бесплатный продукт "VMware Compliance Checker for vSphere", который и проверяет вашу виртуальную инфраструктуру VMware vSphere на соответствие требованиям данного документа.
Основные возможности VMware Compliance Checker for vSphere:
Проверка соответствия нескольких серверов VMware ESX / ESXi в рамках одной сессии (поддерживается только соединение с vCenter).
Сканируются не только хост-серверы, но и vmx-параметры виртуальных машин.
Основан на VMware vSphere Security Hardening.
После того как обследование запущено, можно посмотреть пункты по виртуальным машинам и по типу категории обследования
Ну а теперь самое главное - у российской компании "Код Безопасности" есть бесплатный продукт vGate Compliance Checker, который не только объединяет в себе возможности сканирования виртуальной инфраструктуры на соответствие обоим видам требований по безопасности (Security Hardening и PCI DSS), но и поддерживает сканирование по различным версиям этих стандартов и руководящих документов. То есть, он круче, чем VMware Compliance Checker for vSphere.
Напоминаю, что будущая версия VMware vSphere 5, которая уже выйдет в этом году, будет полностью основана на "тонком" гипервизоре VMware ESXi и не будет иметь в своем составе платформы ESX. То есть, вам всем уже нужно готовиться к переходу на ESXi и все новые инсталляции компания VMware рекомендует делать именно на базе этой платформы.
Как вы знаете, мы начали стратегическое сотрудничество с компанией "Код Безопасности", которая выпускает такой нужный для российского рынка продукт как vGate 2. Он нужен, чтобы автоматизировать работу администраторов по конфигурированию и эксплуатации системы безопасности, а также привести виртуальную инфраструктуру на платформах VMware в соответствие законодательству и отраслевым стандартам. Он имеет сертификат ФСТЭК, что очень нужно при наведении порядка в организации, которая хочет соответствовать нормам ФЗ 152.
Но у компании "Код Безопасности" есть и бесплатный продукт, с которого лучшего всего начать приобщение к продуктовой линейке по обеспечению безопасности VMware vSphere. Это утилита vGate Compliance Checker.
vGate Compliance Checker позволяет проверить соответствие виртуальных инфраструктур на платформах компании VMware требованиям таких стандартов, как PCI DSS и рекомендаций CIS VMware ESX Server Benchmarks и VMware Security Hardening Best Practices. Результатом проверки, которую ИТ-специалисты смогут провести с помощью vGate Compliance Checker, является структурированный отчет (можно экспортировать в HTML), представляющий информацию о положениях стандартов и о соответствии протестированной системы этим положениям. Проверять систему можно произвольно на соответствие только интересующим стандартам и рекомендациям.
Добавим в vGate Compliance Checker сервер VMware ESX (кнопка "Добавить") и запустим проверку безопасности VMware vSphere (кнопка "Запустить").
Начнется сканирование хоста VMware ESX:
После чего, ваш хост ESX конечно не будет соответствовать основным политикам безопасности. Поэтому чтобы узнать, каким именно - нажимаем кнопку "Детали":
Чтобы получить полный отчет в формате html, нужно нажать на кнопку "Сохранить". Отчет vGate Compliance Checker удобно разбит по категориям, соответствующим нормам безопасности виртуальной инфраструктуры VMware vSphere:
Давайте раскроем политику VMware и посмотрим что там внутри:
Как видите, для каждого несоответствия vGate Compliance Checker рассказывает о том, какие именно рекомендации и стандарты нарушены с точки зрения безопасности сервера VMware ESX, а также суть необходимой политики, которую нужно применить в целях повышения уровня безопасности.
Как устранить эти дырки и привести свои серверы ESX в соответствие нормам и стандартам? Ну, во-первых, вы можете воспользоваться материалами нашего сайта, где по тэгу Security можно найти решения для некоторых требований безопасности (например, вот про политики паролей).
Но лучше всего, в целях настоящей безопасности, установить, попробовать, а потом и купить продукт vGate 2, который позволяет держать под контролем безопасность виртуальной инфраструктуры vSphere. Это уже более серьезный уровень, и, если вы озабочены тем, как сделать все правильно с точки зрения Security - не отключайтесь, на следующей неделе мы поговорим про vGate 2 подробнее.
Как мы уже писали, компания StarWind готовится к выпуску версии StarWind Enterprise 5.7, которая будет иметь несколько новых возможностей. О продукте StarWind Enterprise можно почитать тут, тут и тут.
А на днях стала доступна публичная бета-версия StarWind Enterprise 5.7, которую можно скачать в рамках программы тестирования. В статье приведены новые возможности, которые точно появятся в StarWind 5.7.
На сайте проекта VMware Labs (о котором мы уже писали) появился новый интересный продукт - VMware PXE Manager for vCenter. Продукт позволяет настроить автоматизированное развертывание серверов VMware ESXi в виртуальной инфраструктуре.
Основные возможности VMware PXE Manager for vCenter:
Автоматизированное развертывание stateless и stateful хостов ESXi (без поддержки ESX)
Резервное копирование состояния ESXi (firmware), а также восстановление и архивирование в соответствии с политиками
Управление репозиториями билдов ESXi (stateless и statefull)
Управление патчами ESXi
Поддержка нескольких серверов vCenter
Поддержка сложных сетевых конфигураций за счет агентов (позже будет готов виртуальный модуль на базе Linux CentOS, который будет отвечать за развертывание хостов ESXi в своем сегменте датацентра)
Поддержка технологии WoL (Wake on Lan)
Выполнение тестирования памяти хостов ESXi (memtest)
Наличие плагина к vCenter
Развертывание систем в VMware Cloud Director напрямую
Развертывание серверов ESXi на блейд-системах Cisco UCS
Как обещают, эта утилита будет включена в состав платформы VMware vSphere 5. Сам PXE Manager состоит из нескольких компонентов (как и, например, Update Manager) - сервера, устанавливаемого на vCenter, и плагина к vSphere Client. Кроме того, в дочерних датацентрах (например, логических, под управлением Cloud Director) могут быть PXE-агенты в виде виртуальных модулей (это появится позже):
Обзорное видео по установке продукта:
Скачать VMware PXE Manager for vCenter можно по этой ссылке.
В новой версии появилось несколько дополнительных возможностей и параметров поиска по конфигурациям виртуальных систем. Кроме того, появился раздел VMware Aware Storage APIs (VASA, или он же VMware vStorage APIs for Storage Awareness), в котором можно будет найти информацию о поддержке данной технологии, связанной с интеграцией дисковых массивов с vCenter на платформе vSphere (это появится в пятой версии и может оказаться полезным для балансировки нагрузки на системы хранения Storage DRS).
Хорошо, что на свете есть Veeam Backup and Replication 5, который оставил конкурентов на сотни километров позади, и является лучшим на сегодняшний день средством резервного копирования виртуальных машин VMware vSphere. Мы уже писали о новых возможностях Veeam Backup and Replication 5.0, а сегодня рассмотрим нововведения в версиях 5.0.1 и 5.0.2 (последняя вышла не так давно).
Итак, новое в Veeam Backup and Replication 5.0.1:
Поддержка Distributed Virtual Switches (dvSwitch). Теперь это устройство VMware vSphere поддерживается для создания виртуальных лабораторий (Virtual Labs), позволяя еще более гибко подходить к их созданию.
SQL Server Role - новый скрипт для поддержки верификации резервных копий с SQL-серверами с помощью SureBackup.
Automatic failover for Veeam Backup - при попытке забэкапить сам сервер Veeam Backup в режиме Virtual Appliance происходит переключение в Network
mode.
Multi-OS File Level Restore DHCP requirement removed - теперь виртуальный модуль для восстановления файлов из резервных копий не требует наличия DHCP и может работать со статическим IP-адресом.
Multi-OS File Level Restore via FTP - теперь на виртуальном модуле для восстановления файлов можно включить FTP-сервер, который можно использовать в сценариях восстановления для тысяч файлов из гостевых ОС. Также в рамках этого, пользователь конкретной ВМ может восстанавливать файлы самостоятельно.
А вот что нового появилось в версии 5.0.2:
Internet access from virtual lab - теперь при тестировании бэкапов SureBackup в виртуальных лабораториях можно использовать доступ в интернет из этих машин (настраивается в реестре сервера Veeam).
Automated retention for removed and deleted VMs - в интерфейсе можно настроить удаление данных из резервных копий, которые относятся к уже удаленным из окружения vSphere виртуальным машинам. Удаление произойдет через заданное количество дней. Очень удобно для временных и тестовых систем.
Optional catalog import - импорт каталога гостевой ОС теперь не обязателен при импорте бэкапа для Veeam Backup (то есть когда не нужно залезать в гостевую ОС для восстановления, а достаточно восстановить машину целиком). Теперь импорт бэкапа работает быстрее.
Date Modified attribute preservation - теперь при мгновенном восстановлении файлов в ОС Microsoft сохраняется аттрибут Date Modified.
Поддержка Microsoft Windows Storage Server - теперь сюда можно устанавливать Veeam Backup Server и Veeam Enterprise Manager.
Напоминаю, что скачивать Veeam Backup and Replication 5 нужно по этой ссылке, а покупать - по этой.
Как вы уже все знаете, мы очень любим продукт StarWind Enterprise HA (о нем написано тут, тут и в разделе StarWind), который позволяет создавать отказоустойчивые хранилища для виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Это позволяет существенно сэкономить на средствах репликации данных (например, VMware Site Recovery Manager) и не требует покупки дорогостоящих массивов Fibre Channel. То есть можно использовать существующую инфраструктуру Ethernet и дисковые массивы iSCSI, либо вообще серверы-хранилища.
Сегодня компания StarWind запустила промо-программу, в рамках которой можно купить StarWind Enterprise HA со скидкой 5% до конца июня. Продукт нужный - поэтому поторопитесь и закладывайте его в бюджет.
RSS
